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Abstract 

This paper presents a plan-based architecture for re- 
sponse generation in collaborative consultation dia- 
logues, with emphasis on cases in which the system 
(consultant) and user (executing agent) disagree. Our 
work contributes to an overall system for collaborative 
problem-solving by providing a plan-based framework 
that captures the Propose-Evaluate-Modify cycle of col- 
laboration, and by allowing the system to initiate sub- 
dialogues to negotiate proposed additions to the shared 
plan and to provide support for its claims. In addition, 
our system handles in a unified manner the negotiation 
of proposed domain actions, proposed problem-solving 
actions, and beliefs proposed by discourse actions. Fur- 
thermore, it captures cooperative responses within the 
collaborative framework and accounts for why ques- 
tions are sometimes never answered. 



Introduction 

In collaborative expert-consultation dialogues, two par- 
ticipants (executing agent and consultant) work to- 
gether to construct a plan for achieving the execut- 
ing agent's domain goal. The executing agent and the 
consultant bring to the plan construction task different 
knowledge about the domain and the desirable charac- 
teristics of the resulting domain plan. For example, the 
consultant presumably has more extensive and accurate 
domain knowledge than does the executing agent, but 
the executing agent has knowledge about his particu- 
lar circumstances, intentions, and preferences that are 
eithe r restrictions on or potential influencers (Bratman 



1990j) of the domain plan being constructed. In agree 



ing to collaborate on constructing the domain plan, the 
consultant assumes a stake in the quality of the resul- 
tant plan and in how the agents go about construct- 
ing it. For example, a consultant in a collaborative 
interaction must help the executing agent hnd the best 
strategy for constructing the domain plan, may initiate 
additions to the domain plan, and must negotiate with 
the executing agent when the latter's suggestions are 
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not accepted (rather than merely agreeing to what the 
executing agent wants to do). Thus a collaborator is 
more than a cooperative respondent. 

In this paper, we present a plan-based architecture 
for response generation in collaborative consultation di- 
alogues, with emphasis on cases in which the system 
and the user disagree. The model treats utterances as 
proposals open for negotiation and only incorporates 
a proposal into the shared plan under construction if 
both agents believe the proposal to be appropriate. If 
the system does not accept a user proposal, the sys- 
tem attempts to modify it, and natural language ut- 
terances are generated as a part of this process. Since 
the system's utterances are also treated as proposals, a 
recursive negotiation process can ensue. This response 
generation architecture has been implemented in a pro- 
totype system for a university advisement domain. 

Modeling Collaboration 

In a collaborative planning process, conflicts in agents' 
beliefs must be resolved as soon as they arise in order 
to prevent the agents from constructing different plans. 
Hence, once a set of actions is proposed by an agent, 
the other agent must first evaluate the proposal based 
on his own private beliefs (Allen 1991) and determine 
whether or not to accept the proposal. If an agent de- 
tects any conflict which leads him to reject the proposal, 
he should attempt to modify the proposal to a form that 
will be accepted by both agents — to do otherwise is to 
fail in his responsibilities as a participant in collabora- 
tive problem-solving. Thus, we capture collaboration in 
a Propose-Evaluate-Modify cycle. This theory views the 
collaborative planning process as a sequence of propos- 
als, evaluations, and modifications, which may result in 
a fully constructed shared plan agreed upon by both 
agents. Notice that this model is essentially a recursive 
one: the Modify action in itself contains a full collabo- 
rative process — an agent's proposal of a modification, 
the other agent's evaluation of the proposal, and poten- 
tial modification to the modification! 

We capture this theory in a plan-based system for re- 
sponse generation in collaborative task-oriented inter- 
actions. We assume that the current status of the in- 
teraction is represented by a tripartite dialogue model 



(Lambert & Carberry 1991) that captures intentions 
on three levels: domain, problem-solving, and dis- 
cou rse. The domain level contains the domain plan 



bein jg constructed for later execution. The problem- 
solving level contains the agents' intentions about how 
to construct the domain plan, and the discourse level 
contains the communicative plan initiated to further 
their joint problem-solving intentions. 

Each utterance by a participant constitutes a pro- 
posal intended to affect the shared model of domain, 
problem-solving, and discourse intentions. For exam- 
ple, relating a user's query such as Who is teaching AI? 
to an existing tripartite model might require inferring 
a chain of domain actions that are not already part 
of the plan, including Take-Course(User,AI). These in- 
ferred actions explain why the user asked the question 
and are actions that the user is implicitly proposing be 
added to the plan. In order to capture the notion of 



viewed by the system as invalid (Pollack 1986), and one 
in which the system believ es that a better alternative to 
the user's proposal e xists (Joshi, Webber, & Weischedel 



prop osals vs. — shared pla 



a collaborative planning 



snared plans m a cottaooTc 
pro flcQB, wo acparatc the dialogue model into an existing 
model, which consists of a shared plan agreed upon by 
both agents, and the proposed additions, which contain 
newly inferred actions. Furthermo re, we augment Lam- 
bert's plan recognition algorithm (Lambert & Carberry 
199|) wit h a simplified version of Eller's relaxation al- 
gorithm ( Ellcr fc Carberry 1992 ) to recognize ill-formed 
plans. 

We adopt a plan-based mechanism because it is gen- 
eral and easily extendable, allows the same declarative 
knowledge about collaborative problem-solving to be 
used both in generation and understanding, and allows 
the recursive nature of our theory to be represented by 
recursive meta-plans. This paper focuses on one compo- 
nent of our model, the arbitrator, which performs the 
Evaluate and Modify actions in the Propose-Evaluate- 
Modify cycle of collaboration. 

The Arbitration Process 

A proposal consists of a chain of actions for addition to 
the shared plan. The arbitrator evaluates a proposal 
and determines whether or not to accept it, and if not, 
modifies the original proposal to a form that will po- 
tentially be accepted by both agents. The arbitrator 
has two subcomponents, the evaluator and the mod- 
ifier, and has access to a library of generic recipes for 
performing actions]]. 

The Evaluator 

A collaborative agent, when presented a proposal, needs 
to decide whether or not he believes that the proposal 
will result in a valid plan and will produce a reason- 
ably efficient way to achieve the high-level goal. Thus, 
the evaluator should check for two types of discrep- 
ancies in beliefs: one that causes the proposal to be 



A recipe ( [Pollack lgiiej ) is a template for performing 
an action. It encodes the preconditions for an action, the 
effects of an action, the subactions comprising the body of 
an action, etc. 



1984; van Beek 1987). Based on this evaluation, the sys- 
tem determines whether it should accept the user's pro- 
posal, causing the proposed actions to be incorporated 
into the existing model, or should reject the proposal, in 
which case a negotiation subdialogue will be initiated. 

The processes for detecting conflicts and better alter- 
natives start at the top-level proposed action, and are 
interleaved because we intend for the system to address 
the highest-level action disagreed upon by the agents. 
This is because it is meaningless to suggest, for exam- 
ple, a better alternative to an action when one believes 
that its parent action is infeasible. 

Detecting Conflicts About Plan Validity Pol- 
lack argues that a plan can fail because of an i n feasible 
actio n or because the plan itself is ill-formed ( Pollack 



1986). An action is infeasible if it cannot be performed 



by its agent; thus, the evaluator performs a feasibil- 
ity check by examining whether the applicability con- 
ditions of the action are satisfied and if its precondi- 
tions can be satisfied]^]. A plan is considered ill-formed 
if child actions do not contribute to their parent ac- 
tion as intended; hence, the evaluator performs a well- 
formedness check to examine, for each pair of parent- 
child actions in the proposal, whether the contributes 
relationship holds between them^J. The well-formedness 
check is performed before the feasibility check since it is 
reasonable to check the relationship between an action 
and its parent before examining the action itself. 

Detecting Sub-Optimal Solutions It is not suf- 
ficient for the system, as a collaborator, to accept or 
reject a proposal merely based on its validity. If the 
system knows of a substantially superior alternative 
to the proposal, but does not suggest it to the user, 
it cannot be said to have fulfilled its responsibility as 
a collaborative agent; hence the system must model 
user characteristics in order to best tailor its identifi- 
cation of sub-optimal plans to individual users. Our 
system maintains a user model that includes the user's 
preferences. A preference indicates, for a particular 
user, the preferred value of an attribute associated with 
an object and the strength of this preference. The 



2 Applicability conditions are conditions that must al- 
ready be satisfied in order for an action to be reasonable 
to pursue, whereas an agent can try to achieve unsatisfied 
preconditions. Our evaluator considers a precondition satis- 
fiable if there exists an action which achieves the precondi- 
tion and whose applicability conditions are satisfied. Thus 
only a cursory evaluation of feasibility is pursued at this 
stage of the planning process, with further details consid- 
ered as the plan is worked out in depth. This appears to 
reflect human interaction in naturally occuring dialogues. 

s Much of the information needed for the feasibility 
and well-formedness checks will be provided by the plan- 
recognition system that identified the actions comprising the 
proposal. 



preferences are represented in the form, prefers(_user, 
_attribute(_object, .value), .action, .strength), which 
indicates that .user has a .strength preference that 
the attribute .attribute of .object be .value when per- 
forming .action. For instance, prefers (User A, Diffi- 
culty (.course, easy), Take-Course, weak) indicates that 
User A has a weak preference for taking easy courses. 
A companion paper describes our mechanism for recog- 
nizing user preferences during the course of a dialogue 
flElzcr, Chu, k Carberry7994| ) . 

Suppose that the evaluator must determine whether 
an action Ai (in a chain of proposed actions 
A\, . . . , Ai, . . . , A n ) is the best way of performing its 
parent action Ai + \. We will limit our discussion to 
the situation in which there is only one generic action 
(such as Take-Course) that achieves A i+ i, but there are 
several possible instantiations of the parameters of the 
action (such as Take-Course(UserA,CS601) and Take- 
Course(UserA,CS621)). 



The Ranking Advisor The ranking advisor's task 
is to determine how best the parameters of an action 
can be instantiated, based on the user's preferences. 
For each object that can instantiate a parameter of an 
action (such as CS621 instantiating .course in Take- 
Course(UserA,_course)), the evaluator provides the 
ranking advisor with the values of its attributes (e.g., 
Difficulty (CS621, difficult)) and the user's preferences 
for the values of these attributes (e.g., prefers(UserA, 
Difficulty (^course, moderate), Take-Course, weak)). 

Two factors should be considered when ranking the 
candidate instantiations: the strength of the preference 
and the closeness of the match. The strength of a pref- 



ere nce} 4 indicates the weight that should be assigned 
to the preference. The closeness of the match (exact, 
strong, weak, or none) measures how well the actual 
and the preferred values of an attribute match. It is 
measured based on the distance between the two val- 
ues where the unit of measurement differs depending 
on the type of the attribute. For example, for at- 
tributes with discrete values (difficulty of a course can 
be very- difficult, difficult, moderate, easy, or very-easy), 
the match between difficult and moderate will be strong, 
while that between difficult and easy will be weak. The 
closeness of the match must be modeled in order to cap- 
ture the fact that if the user prefers difficult courses, a 
moderate course will be considered preferable to an easy 
one, even though neither of them exactly satisfies the 
user's preference. 

For each candidate instantiation, the ranking advisor 
assigns numerical values to the strength of the pref- 
erences for the relevant attributes and computes the 
closeness of each match. A weight is computed for 
each candidate instantiation by summing the products 



Domain Knowledge: 

Teaches(Smith,CS601) 
Meets- At(CS601,2-3:15pm) 
Difficulty(CS601,dimcult) 
Workload(CS601,moderate) 
Offered(CS601) 

Cont ent ( C S 60 1 ,{ formal-languages , grammar } ) 

Teaches(Brown,CS621) 
Meets- At(CS621,8-9:15am) 
Difficulty(CS621,dimcult) 
Workload(CS621,heavy) 
Offered(CS621) 

Content (CS621, {algorithm-design, complexity-theory}) 

User Model Information: 

Prefers(UserA, Meets-At(_course,10am-5pm), 

.action, very-strong) 
Prefers(UserA, Difficulty (.course, moderate) , 

Take-Course, weak) 
Prefers(UserA, Workload(_course, heavy) , 

Take-Course, low-moderate) 
Prefers(UserA, Content(_course, formal-languages) , 

Take-Course, strong) 

Figure 1: System's Knowledge and User Model Infor- 
mation 



of corresponding terms of the strength of a preference 
and the closeness of a match. The instantiation with 
the highest weight is considered the best instantiation 
for the action under consideration. Thus, the selection 
strategy employed by our ranking advisor corres ponds 



to an additive model of human decision-making (Reed 



1982) 



4 We model six degrees each of positive and negative pref- 
erences based on the conversational circumstances and the 
semantic rep resentation of the utterance us ed to express the 
preferences (Elzer, Chu, & Carberry 1994). 



Example We demonstrate the ranking advisor by 
showing how two different instantiations, CS601 and 
CS621, of the Take-Course action are ranked. Figure |l| 
shows the relevant domain knowledge and user model 
information. 

The ranking advisor matches the user's preferences 
against the domain knowledge for each of CS601 and 
CS621. The attributes that will be taken into account 
are the ones for which the user has indicated pref- 
erences. For each attribute, the advisor records the 
strength of the preference and the closeness of the match 
for each instantiation. For instance, in considering the 
attribute workload, the strength of the preference will 
be low-moderate, and the closeness of the match will 
be strong and exact for CS601 and CS621, respectively. 
Table [j] shows a summary of the strength of the prefer- 
ences and the closeness of the matches for the relevant 
attributes for both instantiations. Numerical values are 
then assigned and used to calculate a final weight for 
each candidate. In this example, the normalized weight 
for CS601 is 43/48 and that for CS621 is 29/48; there- 
fore, CS601 is considered a substantially better instanti- 
ation than CS621 for the Take-Course action for UserA. 





Preference- Strength 


Matcn 




Meets-At 


very-strong 6 


exact 3 


18 


Difficulty 


weak 2 


strong 2 


4 


Workload 


low-moderate 3 


strong 2 


6 


Content 


strong 5 


exact 3 


15 








43 



CS621 


Preference-Strength 


Match 




Meets-At 


very-strong 6 


weak 1 


6 


Difficulty 


weak 2 


strong 2 


4 


Workload 


low-moderate 3 


exact 3 


9 


Content 


strong 5 


strong 2 


10 








29 



Tabic 1 : The Strengths of Preferences and Matches 



The Modifier 

The modifier is invoked when a proposal is rejected. 
Its task is to modify the proposal to a form that 
will potentially be accepted by both agents. The 
process is controlled by the Modify- Proposal action, 
which has four specializations: 1) Correct- Node, for 
when the proposal is infeasible, 2) Correct- Relation, for 
when the proposal is ill-formed, 3) Improve- Action, for 
when a better generic action is found, and 4) Improve- 
Parameter, for when a better instantiation of a parame- 
ter is found. Each specialization eventually decomposes 
into some primitive action which modifies the proposal. 
However, an agent will be considered uncooperative if 
he modifies a proposed shared plan without the collab- 
orating agent's consent; thus, the four specializations 
share a common precondition — that the d iscrepancies 
in beliefs must be squared away ( [Joshi 1982 ) before any 
modification can take place. It is the attempt to satisfy 
this precondition that causes the system to generate 
natural language utterances to accomplish the change 
in the user's beliefs. 

Figure ^ shows two problem-solving recipes, Correct- 
Relation and Modify- Relation, the latter being a sub- 
action of the former. The applicability conditions of 
Correct-Relation indicate that it is applicable when the 
agents, _sl and _s2, disagree on whether a particular 
relationship (such as contributes) holds between two ac- 
tions (_nodel and _node2) in the proposal. The appli- 
cability condition and precondition of Modify-Relation 
show that the action can only be performed if both _sl 
and _s2 believe that the relationship _rel does not hold 
between _nodel and _node2; in other words, the con- 
flict between _sl and _s2 must have been resolved. The 
attempt to satisfy this precondition causes the system 
to invoke discourse actions to modify the user's beliefs, 
which can be viewed as initiating a negotiation subdi- 
alogue to resolve a conflict. If the user accepts the sys- 
tem's beliefs, thus satisfying the precondition of Modify- 
Relation, the original dialogue model can be modified; 
however, if the user rejects the system's beliefs, he will 
invoke the Modify -Proposal action to revise the system's 
suggested modification of his original proposal. 



Action: 
Type: 

Appl Cond: 
Constraints: 



Body: 



Effects: 
Goal: 

Action: 

Type: 

Appl Cond: 

Preconditions: 

Body: 

Effects: 
Goal: 



Figure 2: 
Recipes 



Correct- Relational, _s2, .proposed) 
Decomposition 

believe(_sl, -nholds( jel, jiodel, jiode2)) 
believe( _s2 , holds (_rel, _node 1 , _node2) ) 
error- in- plan ( .relation , _prop osed) 
name-of (.relation, _rel) 
parent-node(_relation, _node2) 
child-node(_relation, jiodel) 
Modify-Relation (_sl, _s2, .proposed, 

_rel, _nodel, _node2) 
Insert-Correction(_sl, _s2, .proposed) 
modified ( .proposed) 
well-formed(_proposed) 

Modijy-Relation(_sl, _s2, .proposed, 

_rel, _nodel, jiode2) 

Specialization 

believe(_sl, -nholds( jel, jiodel, jiode2)) 
believe( _s2 , -nholds ( jel, jiode 1 , jiode2) ) 
Remove-Node(_sl, _s2, .proposed, jiodel) 
Alter-Node(_sl, _s2, .proposed, jiodel) 
modified (.proposed) 
modified (.proposed) 

Correct- Relation and Modify-Relation 



In order to retain as much of the original proposal as 
possible when modifying a proposal, Modify-Relation 
has two specializations: Remove-Node and Alter-N ode. 
The former is selected if the action itself is inappropri- 
ate, and will cause the action to be removed from the 
dialogue model. The latter is chosen if a parameter is 
inappropriately instantiated, in which case the action 
will remain in the dialogue model and the problematic 
parameter will be left uninstantiated. 

Example of Correcting an Invalid Proposal 

Suppose earlier dialogue suggests that the user has 
the goal of getting a Master's degree in CS (Get- 
Masters (U, CS)). Figure |] illustrates the dialogue model 
that would result from the following utterances. 

(1) U: I want to satisfy my seminar course require- 

ment. 

(2) Who is teaching AI? 

The evaluation process, which determines whether or 
not to accept the proposal, starts at the top-level pro- 
posed domain action, Satisfy-Seminar-Course(U,CS). 
Suppose the system believes that Satisfy- Seminar- 
Course(U,CS) contributes to Get-Masters(U,CS), that 
U can perform Satisfy-Seminar-Course(U,CS), and 
that there is no better alternative to the instantiation 
of Satisfy- Seminar- Course. The evaluator then checks 
its child action Take- C our se(V ,AI) . The system's recipe 
library indicates that Take-Course(U,AI) does not con- 
tribute to Satisfy-Seminar-Course(U,CS), since it be- 
lieves that AI is not a seminar course, causing the pro- 
posal to be rejected. 



Domain Level 

Get-Maslers(U,CS) 



Proposed Domain Level 



Problem-Solving Level 



ISalisfy-Seminar-CoLirsdL'.CS) 

Take-CoursdL'.AI) [ <- .J 



Build-Plan(U.S,Get-Masters(U,CS)) 

A 



Proposed Problem-Solving Level 



Discourse Level 



JBuild-Plan(U.S.Satisfy-SL-minar-C»urse(U,CS)) 
Build-Plan(U,S,Take-Course(U,AI)) " 



Instantiate- Vars(U,S,Learn-Material(U,AI,_fac), 
Takc-Cutii-sL-(U.Al)) 

t 



Instantiate-Single-Var(U,S,_fac, 
Learn-Matei-ral(U.AI._fac),Takc-Cuiiisc(U,Al)) 



Obtam-Info-Ref(U,S,_fac,Teaches(_fac,AI)) 
Ask-Ref(U,S,_fac,Teaches(_fac,AI)) 



|Make-Q-Acceplablc(LI,S,Tcachcs(_fac,Al)) 

. * , 

Give-Backsround(U.S,Tcaches(_iac,AI)) 

t 



Unform(U,S.want(L',Salisl\-Scminai--CuLiisc(U,CS))) 



Tell(U,S, want(U, 

Satisfy-Seminai-Cuiirse(U,CS))) 



Surface-Say-Prop(U,S,want(U, 

Satisfy-Seminar-Course(U,CS))) 



/ want to satisfy my seminar course requirement. 



Ref-Request(U,S,_fac, 
Teaches(_fac,AI)) 

T 

Surface- WH-Q(U,S,_fac, 
Teaches(_fac,AI)) 

Who is teaching AI? 



Figure 3: The Dialogue Model for Utterances (§)-(H) 



The modifier performs the Modify-Proposal action, 
which selects as its specialization Correct- Relation, be- 
cause the rejected proposal is ill-formed. Figure f| 
shows the arbitration process and how Correct- Relation 
is expanded. Notice that the arbitration process 
(the problem-solving level in Figure B) operates on 
the entire dialogue model in Figure |, and there- 
fore is represented as meta-level problem-solving ac- 
tions. In order to satisfy the precondition of Modify- 
Relation, the system invokes the discourse action In- 
form as an attempt to change the user's belief (in 
this case, to achieve believe(U,^holds( contributes, Take- 
Course(U,AI), Satisfy-Seminar-Course(U,CS)))). The 
Inform action further decomposes into two actions, one 
which tells the user of the belief, and one which pro- 
vides support for the claim. This process will generate 
the following two utterances: 

(3) S: Taking AI does not contribute to satisfying 

the seminar course requirement. 

(4) AI is not a seminar course. 

If the user accepts the system's utterances, thus sat- 
isfying the precondition that the conflict be resolved, 
Modify -Relation can be performed and changes made 
to the dialogue model. In this example, the proposal is 
rejected due to an inappropriate instantiation of the pa- 
rameter .course; thus Modify-Relation will select Alter- 



Dialogue Model in Figure 3 



Proposed Problem-Solving Level 



Arbitrate(S,U,Proposed-Model) 


Evaluate-Proposal(S,U, 
Proposed -Model) 




Modifv-Proposal(S.U.Proposed-Model) 


t 






Correct-Relation(S,U,Proposed-Model) 


t 






Modify-Relation(S,U,Proposed-Model, 






contributes, Take-Course(U,AI), 






Satisfy-Seminar-Course(U,CS)) 



Discourse Level 



Inform(S,U, ~holds(contributes, Take-Course(U,AI), 
Satisfy-Seminar-Course(U,CS))) 



Tell(S,U, ~holds(contributes, 
Take-Course(U.AI), 
Satisfy-Seminar-Course(U,CS))) 



Address-Acceptance(S,U, 
~holds(contributes, Take-Course(U,AI), 
Salisl'y-Scminar-Course(U,CS))) 



Surface-Say-Prop(S,U. 
~holds(contributes, Take-Course(U,AI), 
Satisfy-Seminar-Course(U,CS)))) 



Infoi"m(S,U, ~isa(AI, seminar-course)) 



Taking AI does not contribute to satisfying Tell(S,U, ~isa(AI seminar-course)) 
the seminar course requirement. f 



Surface-Say-PropfS,U, ~isa(Al, seminar-course)) 



AI is not a seminar course. 



Figure 4: Responding to Implicitly-Conveyed Conflicts 



Node as a specialization to replace all instances of AI 
in the dialogue model with a variable. This variable 
can be reinstantiated by Insert- Correction, the second 
subaction of Correct-Relation. 

Assuming that the system and the user encounter no 
further conflict in reinstantiating the variable, the arbi- 
tration process at the meta-level is completed and the 
original dialogue is returned to. The proposed additions 
now consist of actions agreed upon by both agents and 
will therefore be incorporated into the existing model. 
Notice that our model separates the negotiation sub- 
dialogue (captured at the meta level) from the original 
dialogue while allowing the same plan-based mechanism 
to be used at both levels. It also accounts for why the 
user's original question about the instructor of AI is 
never answered a conflict was detected that made the 
question superfluous. Thus certain situations in which 
questions fail to be answered can be accounted for by 
the collaborative process rather than being viewed as a 
violation of cooperative behaviour. 

Example of Suggesting Better Alternatives 

Consider the following utterances, whose dialogue 
model has the same structure as that for utterances 
d) and (@) (Figure |). 

(5) U: I want to satisfy my theory course require- 

ment. 

(6) Who is teaching CS621? 

For space reasons, we skip ahead in the eval- 
uation process to the optimality check for Take- 
Course(U,CS621). There are two instantiations of 
.course that satisfy the constraints specified in the 



recipe for Satisfy-Theory-Course: CS601 and CS621. 
These are ranked by the ranking advisor based on the 
user's preferences, summarized in Table El which sug- 
gests that CS601 is a substantially better alternative to 
CS621. Thus, Improve-Parameter is selected as a spe- 
cialization of Modify- Proposal. Similar to the previous 
example, the Inform discourse action will be invoked as 
an attempt to resolve the discrepancies in beliefs be- 
tween the two agents, which would lead to the genera- 
tion of the following utterances: 

(7) S: CS601 is a better alternative than CS621. 

(8) CS601 meets at 2pm and involves formal lan- 
guages and grammar. 

Notice that utterance (||) provides supporting evidence 
for the claim in (]?]), and is obtained by comparing the 
sets of information used by the ranking advisor (Ta- 
ble and selecting the features that contribute most 
to making CS601 preferable to CS621. 

The Belief Level 

We showed how our arbitrator detects and resolves 
conflicts at the domain level. Our goal, however, is to 
develop a mechanism that can handle negotiations at 
the domain, problem-solving, and discourse levels in a 
uniform fashion. The process can be successfully ap- 
plied to the problem-solving level because both the do- 
main and problem-solving levels represent actions that 
the agents propose to do (at a later point in time for the 
domain level and at the current time for the problem- 
solving level); however, the discourse level actions are 
actions that are currently being executed, instead of pro- 
posed for execution. This causes problems for the modi- 
fication process, as illustrated by the following example. 

(9) U: I want to take AI. 

(10) Dr. Brown is teaching AI, 

(11) since he is a full professor. 



Utterance (|llj) provides support for (|Hj), which sup- 
ports (||). However, if the system believes that whether 
one is a full professor has no relation to whether or not 
he teaches AI, the system and the user have a conflict 
as to whether (^Tj) supports ([lO]). Problems will arise if 
the system convinces the user that Dr. Brown teaches 
AI because that is his area of specialty, not because 
he is a full professor, and attempts to modify the dia- 
logue model by replacing the Inform action that repre- 
sents ( |Tl| ) with one that conveys specializes (Br own, AI). 
This modification is inappropriate because it indicates 
that the user informed the system that Dr. Brown spe- 
cializes in AI, which never happened in the first place. 
Therefore, we argue that instead of applying the arbi- 
tration process to the discourse level, it should be ap- 
plied to the beliefs proposed by the discourse actions. 

In order to preserve the representation of the dis- 
course level, and to handle the kind of conflict shown in 
the previous example, we expand the dialogue model to 



Proposed Domain Level 

\ I Take-Course(U,AI) 
Proposed P-S Level 
|Build-Plan(U,S,Take-Couise(U,AI)) 
Proposed Belief Level 

_ , MB(U,S,want(U,Take-Course(U,Al)))~ 
| supports 

' |MB(U,S,Teaches(Brown,Al)) h - _ 
i | supports 

|MB(U,S,lsa(Brown,Full-Professor))~l - 
Discourse Level 



[Tel 
/ want to take AI. 



lnfoi-m(U,S,want(U,Take-Course(U,AI))) , \ 

lAddress-Acceptance ' 1 

t / 
|lnform(U.S.Teaches(Brown.AI)) V \ 

" > . ; 

pY~[|| | Address- Acceptance | i 

Dr. Brown is teaching AI, |i n f orm(U , S ,lsa(Brow!,Full-Profe^r))~ 
since he is a full professor. 



Figure 5: The Four-Level Model for Utterances (H)-(U 



include a belief level. The belief level captures domain- 
related beliefs proposed by discourse actions as well as 
the relationship amongst them. For instance, an In- 
form action proposes a mutual belief (MB) of a propo- 
sition and an Obtain-Info-Ref action proposes that both 
agents come to know the referent (Mknowref) of a pa- 
rameter. Thus, information captured at the belief level 
consists not of actions, as in the other three levels, but 
of beliefs that are to be achieved, and belief relation- 
ships, such as support, attack, etc. 

Discourse Level Example Revisited Figure || out- 
lines the dialogue model for utterances (H)-(O) with 
the additional belief level. Note that each Inform ac- 
tion at the discourse level proposes a mutual belief, 
and that supports relationships (inferred from Address- 
Acceptance) are proposed between the mutual beliefs. 

The evaluation process starts at the proposed do- 
main level. Suppose that the system believes that 
both Take-Course(U,AI) and Build- Plan (U,S, Take- 
Course(U,AI)) can be performed. However, an exami- 
nation of the proposed belief level causes the proposal 
to be rejected because the system does not believe that 
Dr. Brown being a full professor supports the fact 
that he teaches AI. Thus, Correct- Relation is selected 
as the specialization of Modify-Proposal in order to re- 
solve the conflict regarding this supports relationship. 
Again in order to satisfy the precondition of modify- 
ing the proposal, the system invokes the Inform action 
which would generate the following utterance: 

(12) S: Dr. Brown being a full professor does not 
provide support for him teaching AI. 

Thus, with the addition of the belief level, the arbi- 
trator is able to capture the process of evaluating and 
modifying proposals in a uniform fashion at the domain, 



problem- solving, and belief levels. An additional ad- 
vantage of the belief level is that it captures the beliefs 
conveyed by the discourse level, instead of how they are 
conveyed (by an Inform action, by expressing doubt, 
etc.). 



Related Work 



Allen ( 1991 ) proposed different plan modalities that 
capture the shared and individual beliefs du ring col- 
lab oration, and Grosz, Sidner and Lochbaum ( |Grosz fc 



Sidr |er 1990 ; Lochbaum 1991 ) proposed a SharedPlan 



model for capturing intentions during a collaborative 
process. However, they do not address response gen- 
eration during collaboration. Litman and Allen (1987) 
used discourse meta-plans to handle correction subdi- 
alogues. However, their Correct-Plan only addressed 
cases in which an agent adds a repair step to a pre- 
existing plan that does not execute as expected. Thus 
their meta-plans do not handle correction of proposed 
additions to the dialogue model, since this generally 
does not involve adding a step to the proposal. Fur- 
thermore, they were only concerned with understanding 
utterances, not with gener ating appropriate respo nses. 



Heeman and Hirst (1992) and Edmonds ( |l993 ) use 
meta-plans to account for collaboration, but their mech- 
anisms are limited to understanding and generating re- 
ferring expressions. Although Heeman is extending his 
model to account for collaboration in task-oriented di- 



alogues ( Heeman 1993 ), his extension is limited to the 
recognition of ac tions in such dialogues. Guinn and 
Biermann ( 1993 ) developed a model of collaborative 
problem-solving which attempts to resolve conflicts be- 
tween agents regarding the best path for achieving a 
goal. However, their work has concentrated on situa- 
tions in which the user is trying to execute a task under 
the system's guidance rather than those where the sys- 
tem and user are collaboratively developing a plan for 
the user to execute at a later point in time. 

Researchers have utilized plan-based mechanisms to 
generate natural language responses, including expla- 



nations ( |Moore fc Paris 1993| ; Maybury 1992; Cawsey 
199|). However, they only handle cases in which the 
user fails to understand the system, instead of cases 
i n wh ich the user disagrees with the system. Maybury 
( |1993| ) developed plan operators for persuasive utter- 
ances, but does not provide a framework for negotiation 
of conflicting views. 

In suggesting better alternatives, our system differs 
from van Beek's ( 1987 ) in a number of ways. The most 
significant are th at our system dynamically rec ognizes 
user preferences (Elzer, Chu, fc Carberry 1994), takes 



into account both the strength of the preferences and 
the closeness of the matches in ranking instantiations, 
and captures the response generation process in an over- 
all collaborative framework that can negotiate propos- 
als with the user. 



Conclusions and Future Work 

This paper has presented a plan-based system that cap- 
tures collaborative response generation in a Propose- 
Evaluate- Modify cycle. Our system can initiate subdia- 
logues to negotiate implicitly proposed additions to the 
shared plan, can appropriately respond to user queries 
that are motivated by ill-formed or suboptimal solu- 
tions, and handles in a unified manner the negotia- 
tion of proposed domain actions, proposed problem- 
solving actions, and beliefs proposed by discourse ac- 
tions. In addition, our system captures cooperative re- 
sponses within an overall collaborative framework that 
allows for negotiation and accounts for why questions 
are sometimes never answered (even in the most coop- 
erative of environments). 

This response generation architecture has been im- 
plemented in a prototype system for a university ad- 
visement domain. The system is presented with the ex- 
isting dialogue model and the actions proposed by the 
user's new utterances. It then produces as output the 
logical form for the appropriate collaborative system 
response. In the future, we will extend o ur system to 
include vario us argumentati on strategies ( Bycara 1989] ; 
Quilici 1991; Maybury 1993) for supporting its claims. 
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